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(54) Document transfer systems 

(57) A document transfer system enabling a con- 
sumer to obtain a document from an owner upon pay- 
ment uses a cryptographic protocol involving the 
consumer, the owner, a document source, such as a 
printer, and a mediator, the protocol comprising the fol- 
lowing steps: 

(a) the consumer requests a document; 

(b) the owner provides the source with first and 
third portions of the key and provides the medi- 
ator with a fourth portion of the key, which can 
combine with said first portion to generate the 
complete key; 

(c) the consumer provides the owner with the pay- 
ment; and 

(d) the owner provides the source with a second 
portion of the key, which can combine with said 
first portion to generate the complete key. 

A printer (1) for use in the above system comprises 
a document memory (2) for storing a received 
encrypted document, a key memory (3) for storing a first 
cryptographic key portion, a processor (4) for receiving 
a second cryptographic key portion and combining it 
with the first key portion to form a complete crypto- 
graphic key which is supplied to a decrypting module 
(5). The encrypted document is supplied to the decrypt- 
ing module (5) whereupon the document is decrypted 
and supplied to the consumer. 
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Description 

[0001] The present invention relates to document 
transfer systems and in particular relates to such sys- 
tems involving cryptographic protocols enabling a docu- 5 
ment to be obtained by a consumer upon payment to 
the owner of the document. 

[0002] It would be desirable for the protocol to have 
strong fairness properties, i.e. a guarantee that, at the 
end of the protocol, either both the owner and the con- 10 
sumer receive payment and the document respectively, 
or neither party receives anything useful. 
[0003] There is a substantial body of work on fair 
exchange and cryptographic services which use this 
primitive. For protocols requiring fairness in the absence is 
of third parties, the definition of fairness is necessarily 
probabilistic, and such protocols are usually based on 
the gradual release of secrets. The following documents 
describe recent work on practical proposals for fair 
exchange which use a third party with varying trust 20 
assumptions: 

(a) Matthew K. Franklin and Michael K. Reiter, Fair 
Exchange with a Semi-Trusted Third Party, Pro- 
ceedings of the 4th ACM Conference on Computer 25 
and Communications Security, 1997; this document 
describes a fair exchange protocol with a semi- 
trusted third party with trust assumptions similar to 
those used in the present invention. The third party 
inthis case, however, is online even if the parties fol- 30 
low the protocol faithfully; 

(b) Silvio Micali, An efficient off-line electronic cash 
scheme based on the representation problem, 
Technical Report CS-R9323, CWI, Amsterdam, 
1993; this document describes an optimistic proto- 35 
col for certified electronic mail with sleeping post 
offices; 

(c) N. Asokan, M. Schunter and M. Waidner, Opti- 
mistic Protocols for Fair Exchange, Proceedings of 
the 4th ACM Conference on Computer and Com- 40 
munications Security, 1997; this document 
describes a practical optimistic protocol for fari 
exchange. However, this protocol increases the 
trust requirements on the third party in the event of 

a dispute resolution being required. In particular, 45 
the third party inspects the contents of a message 
containing the item being exchanged while resolv- 
ing disputes. In addition, the described protocol 
family has a synchronous time model which may 
not be suitable for certain applications. so 

[0004] In accordance with a first aspect of the present 
invention there is provided a cryptographic method of 
enabling a consumer to obtain a document from an 
owner upon a payment as defined in Claim 1 . 55 
[0005] In accordance with a second aspect of the 
present invention there is provided a cryptographic 
method of enabling a consumer to obtain a document 
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from an owner upon a payment as defined by Claim 2. 
[0006] The first and third portions of the key are pref- 
erably different. 

[0007] Hie method may be arranged for enabling a 
said consumer to receive a plurality of such documents, 
wherein said key is divided into different respective sets 
of portions for each document. 
[0008] The document source is preferably a printer. 
[0009] In the preferred embodiment, the ordering pro- 
tocol is carried out in the presence of a mediator with 
minimal trust assumptions. The protocol is optimistic, in 
that the mediator remains off-line except in the case of 
dispute resolution. In addition, the mediator does not 
learn any information about the document, even in the 
event of a dispute. 

[001 0] In accordance with a third aspect of the present 
invention there is provided a document source for use in 
one of the above-described methods as defined by 
Claim 7. 

[0011] In accordance with a fourth aspect of the 
present invention, there is provided a document source 
as defined by Claim 8. 

[0012] The document source is preferably a printer 
which is advantageously arranged to print a number of 
copies of a said document in each of a plurality of for- 
mats. 

[001 3] The printer may be arranged to print only one 
copy of a said document in a first format and an unlim- 
ited number of copies of said document in a second for- 
mat. 

[001 4] The formats may comprise different resolutions 
or a choice of monochrome and colour images. 
[001 5] In accordance with a fifth aspect of the present 
invention, there is provided a fair exchange method of 
enabling a consumer to obtain a document from an 
owner upon a payment as defined by Claim 1 4. 
[0016] In accordance with a sixth aspect of the 
present invention there is provided a cryptographic 
method of enabling a first party to obtain an item of 
value from a second party upon receipt by said second 
party of a second item of value as defined by Claim 15. 
[0017] In accordance with a seventh aspect of the 
present invention there is provided a fair exchange 
method of enabling a contract between a buyer and a 
seller of a commodity as defined in Claim 16. 
[0018] A preferred embodiment of the present inven- 
tion will now be described with reference to the accom- 
panying drawing which illustrates the protocol of the 
preferred embodiment. 

[001 9] The parties involved in the protocol are: 

(a) The owner O of a printable document who 
wishes to charge end users for prints of the docu- 
ment. For the purposes of payment, the copyright 
owner adopts the role of a merchant in SET termi- 
nology; 

(b) The consumer C who wishes to print the copy- 
righted material and pay for it. C assumes the role 
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of cardholder in SET terminology for the payment 
phase. 

(c) The printer P which is the physical printer device 
intended to print the document. The printer can sign 
random nonces and perform EIGamal decryptions. 5 
It has its private signing key in a temper-resistant 
store. Its function upon receipt of a document is to 
run the protocol to recover the encryption key and 
thereafter to decrypt and render the document. The 
printer can understand a copyright specification 10 
language and is trusted by the owner to follow the 
agreement. The printer does not need to verify any 
signatures, this being performed by the consumer. 
There is thus no requirement that any set of trusted 
root keys be maintained; is 

(d) The mediator M, a semi-trusted third party who 
mediates the transaction between the owner and 
the consumer and who can arbitrate in the event 
that the parties do not follow the protocol. 

20 

[0020] As can be seen from the above, there is a dis- 
tinction between the two roles of the consumer and the 
printer. This is important, because of the underlying 
trust assumption, namely that the printer can be 
entrusted by the owner to respect the conditions of a 25 
copyright agreement, whereas it may not be reasonable 
to assume that the consume would do the same. 
[0021] The requirement for a payment protocol are 
that a payment request can be linked to some order 
information in a non-repudiable manner and that it is 30 
possible for the consumer to query the status of a pay- 
ment request. For illustration, the SET protocol is used 
below to describe the payment phase. 
[0022] The parties share a large Sophie Germain 
prime number p, i.e. one satisfying the relation: 35 

where q is also a prime number. 

[0023] The documents are distributed in an encrypted 40 
manner using offline or online means. The (bulk) 
encryption uses key material derived from an integer x 
€ Fp. This can be done, for example, by computing a 
one-way transformation H(x) and using some output 
bits as the initialisation vector (IV) and bulk enciphering 45 
key k. 

[0024] The protocol has the following properties: 

The secret corresponding to a document is not 
revealed to the consumer. so 
If the owner deviates from the protocol, the con- 
sumer has an undeniable proof linking the owner to 
the (incomplete) transaction. It can resolve the dis- 
pute with the mediator. This is the only trust 
assumption on the mediator - in case the owner ss 
deviates from the protocol, it promises to perform 
the dispute resolution steps faithfully. 
In the event of a secret associated with a document 



being invalid, the printer can provably demonstrate 
its invalidity. 

- The mediator does not gain any knowledge of the 
secret unless one of the parties reveals the neces- 
sary information. 

The protocol is optimistic - if parties execute the 
protocol steps faithfully, mediation is not required. 

[0025] The parties share parameters (g, h) where g 
generates a multiplicative group of prime order p. The 
element h generates a multiplicative group of prime 
order q = (p- 1) /2. The group orders should be cho- 
sen such that the discrete logarithm problem is hard in 
the corresponding multiplicative groups. Computations, 
unless otherwise specified, occur in the finite field Fp. 
[0026] The parties choose secrets in Fg and publish 
corresponding public keys in Fp. The mediator's public 
key is: 




and the owner's public key is: 

The printer and owner use a signature mechanism a 
such that the printer's signature a p and v 0 are verifiable 
by the owner, the consumer and the mediator. 
[0027] A public commitment C(x) - g* mod p to the 
bulk encryption key is attached to the encrypted content 
and signed by the owner. We use a protocol described 
in a paper by Markus Stadler, entitled Publicly Verifiable 
Secret Sharing (Advances in Cryptology - EUROC- 
RYPT '96, Lecture Notes in Computer Science, 1070 
(1996), 190 - 199) to publicly verify the fink between a 
commitment of the form g* mod p, and the EIGamal 
encryption of the associated secret x in a known public 
key using a computationally zero knowledge argument. 
This arrangement is shown in Figure 1 . 
[0028] Prior to ordering a document, the owner and 
consumer agree on a mediator acceptable to both par- 
ties. The parties also agree upon an acceptable copy- 
right agreement specified in a manner that is 
understood by the printer. We denote this string by R. 
[0029] The owner generates a nonce n 0 e Z/p Z and 
sends it to the consumer to initiate the protocol. 
[0030] The consumer sends the document's published 
value the copyright string R and the owner's nonce 
n 0 to the printer. The printer checks if the string R spec- 
ifies controls that it can perform. If this is the case, it 
generates a random number r p e Z/qZ, computes the 
nonce: 
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and sends the tuple {n 0 n p Ft) signed to the consumer. 
The nonce n p will be treated by the printer as a one-time 
public key exchange key for this transaction. The printer 
internally keeps track of the association between the 
copyright string, the public commitment and its own 5 
one-time key. 

[0031] The consumer passes the printer's signed 
message on to the owner, in addition to any payment- 
related payload indicating initialisation (for SET, this will 
be a message to the merchant requesting a wake-up of 10 
the consumer's wallet software). 
[0032] The owner, on receipt of the print request, gen- 
erates a random value of w between 1 and q - 1 . It now 
shares x between the printer and the mediator using a 
publicly-verifiable 2-out-of-2 sharing scheme. 15 
[0033] Secret sharing is effected by performing an 
EIGamal encryption of w using the printer's one-time 
key exchange key n p and of x - w in the mediator's pub- 
lic key y m . 

[0034] The owner generates EIGamal tuples: 20 

X p = (hWp/w) andX m = (h*,y s m /(x-w)) 
for some values of r, s chosen uniformly at random from 

[1 Q-1]. 25 

[0035] The values g w and g*~ w t encrypted tuples X m 
and X p and tuple (n 0 , R) are now sent signed to the 
consumer in addition to any payment-related payload 
(for SET, this would be the wake-up message to the 
consumer's wallet and would include the order data 30 
component from the owner). 

[0036] The consumer (without input from the printer) 
can verify that the sharing was correctly performed by 
the owner, and that the encryption is valid. This is 
effected using the protocol defined in the above-men- 35 
tioned paper by Stadler. 

[0037] The consumer now generates its payment 
message signifying an intended purchase for the key 
material x. The payment request is cryptographically 
linked with the nonces associated with the transaction. 40 
In case of SET, the transaction would be linked to the 
Order Data element in the protocol message. 
[0038] Upon validation of the payment request, the 
owner now sends the other half of the bulk decryption 
key encrypted in the one-time key exchange key n p ; that 45 
is, it sends X' p = (h\ n* p /(x-w)) to the consumer. 
This is bound with the nonce pair and signed by the 
owner. 

[0039] The printer, once in possession of the EIGamal 
pairs X p and X p recovers x using its one-time secret r p . 50 
It can now decrypt the document using x to derive the 
bulk decipherment key. The printer then proceeds to 
print the document in agreement with the associated 
copyright • agreement R. 

[0040] The above protocol is shown diagrammatically ss 
in the accompanying drawing. 
[0041] The optimistic version of the protocol favours 
the copyright owner, because the consumer pays for the 



goods before the encryption key is released by the 
owner. 

[0042] In case of disputes, the consumer can present 
the public transaction details (% n p R), the encrypted 
shares X p and X m and the payment information to the 
mediator. The mediator can verify the cryptographic link 
between the payment and the mediator's share. Once 
this is done, she queries the owner with the transaction 
ID of the payment. Upon receipt of a satisfactory 
response (or no response at ail), she extracts her share 
{x -w) and supplies an EIGamal encryption of (x - w) in 
the appropriate one-time key exchange key of the 
printer. Since EIGamal encryption is a randomised con- 
struction, this will result in a different EIGamal pair with 
a probability approaching 1 . 

[0043] In addition, the SET 1.0 payment protocol 
requires resolution outside of the protocol if the mer- 
chant does not deliver an InqRes back to the mediator. 
[0044] The following demonstrates that the protocol is 
i-resilient, i.e. any one party can deviate from the proto- 
col without compromising its security, under the deci- 
sion Diffie-Hellman assumption. The decision Diffie- 
Hellman assumption is described in a paper by Stefan 
Brands entitled An efficient off-line electronic cash 
scheme based on the representation problem (Techni- 
cal Report CS-R9323, CWI, Amsterdam, 1993): 

The moderator only knows (x - w) and hence does 
not learn anything about the secret x unless one of 
the parties discloses it. This holds even if the mod- 
erator resolves a dispute successfully. 

If the consumer deviates by not providing a valid 
payment message, the owner aborts the protocol. 
Since the secret sharing is perfect zero knowledge, 
no information about x is revealed. 

- If the owner does not provide the final encryption 
Xp of (x - w), the consumer can request the moder- 
ator to decrypt its share X m . The moderator can 
now compute (x - w) and send it to the consumer 
encrypted in the printer's one-time key exchange 
key Hp. 

The consumer cannot reply previously collected 
printer tokens (EIGamal signatures by the owner) to 
the printer, because the key exchange key for the 
printer, n pt will be different from a previous transac- 
tion with a probability approaching 1 . 

- An arbitrary party can build shares corresponding 
to some x\ but it is the consumer's responsibility to 
tie the commitment of of x' to the owner's identity 
by verifying the owner's signature. 

[0045] The zero-knowledge protocol described in the 
above-mentioned paper by Stadler has a round effi- 
ciency of 1 >£ and hence requires a significant number of 
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rounds to reduce the error probability acceptably. As 
noted in Stadler, this proof can be made non-interactive. 
As a result, the proof need not be performed online by 
the consumer. Instead, the consumer only checks if the 
public commitments C, =g w and C 2 =g x ' w match 
the document's public value C = g x , i.e. whether the 
relation C r C 2 = C holds true. 
[0046] In case of a dispute, the mediator can decrypt 
and verify her share (x-w). She can now run the proof 
for the printer's share X p . As a result, the protocol is 
optimistic but fair. 

[0047] A printer for use in the above methods is 
described with reference to Figure 2. The printer 1 com- 
prises a document memory 2 for storing a received 
encrypted document, a key memory 3 for storing a 
received first cryptographic key portion from the owner, 
a processor 4 for receiving a second cryptographic key 
portion from the owner and combining it with the first 
key portion stored in the key memory 3 to form a com- 
plete cryptographic key which is supplied to a decrypt- 
ing module 5. The encrypted document stored in the 
document memory 2 is supplied to the decrypting mod- 
ule 5 whereupon the document is decrypted and sup- 
plied to the consumer. 

Claims 

1 . A cryptographic method of enabling a consumer to 
obtain a document from an owner upon a payment, 
the method comprising the use of a protocol involv- 
ing the consumer, the owner and a document 
source, wherein the source requires knowledge of a 
key in which a said document is encrypted in order 
to provide the said document, the protocol compris- 
ing the following sequential steps: 

(a) the consumer requests a specified docu- 
ment; 

(b) the owner provides the source with a first 
portion of the key; 

(c) the consumer provides the owner with the 
payment; and 

(d) the owner provides the source with a sec- 
ond portion of the key, which can combine with 
said first portion to generate the complete key. 



(b) the owner provides the source with first and 
third portions of the key and provides the medi- 
ator with a fourth portion of the key, which can 
combine with said third portion to generate the 

5 complete key; 

(c) the consumer provides the owner with the 
payment; and 

(d) the owner provides the source with a sec- 
ond portion of the key, which can combine with 

w said first portion to generate the complete key. 

3. A cryptographic method as claimed in Claim 2, 
wherein said first and said third portions of the key 
are different. 

15 

4. A cryptographic method as claimed in Claim 2 or 
Claim 3, and arranged for enabling a said consumer 
to receive a plurality of such documents, wherein 
said first and second portions are different for each 

20 document 

5. A cryptographic method as claimed in any one of 
Claims 2 to 4, wherein the mediator is involved in 
the protocol only in the event of a dispute between 

25 the owner and the consumer. 

6. A cryptographic method as claimed in any preced- 
ing claim, wherein the document source comprises 
a printer. 

30 

7. A document source for use in a method as claimed 
in any preceding claim, the source comprising a 
memory for storing a said first key portion, means 
for receiving a said second key portion and means 

35 for decrypting an encrypted document transmitted 
thereto in accordance with the encryption key 
defined by said first and said second key portions. 

8. A document source comprising a memory for stor- 
40 ing a first cryptographic key portion, means for 

receiving a second cryptographic key portion and 
means for decrypting an encrypted document 
transmitted thereto in accordance with the encryp- 
tion key defined by said first and said second key 
45 portions. 



2. A cryptographic method of enabling a consumer to 
obtain a document from an owner upon a payment, 
the method comprising the use of a protocol involv- 
ing the consumer, the owner, a document source so 
and a mediator, wherein the source requires knowl- 
edge of a key in which a said document is 
encrypted in order to provide the said document, 
the protocol comprising the following sequential 
steps: 55 

(a) the consumer requests a specified docu- 
ment; 



9. A document source as claimed in Claim 7 or Claim 
8 comprising a printer. 

1 0. A document source as claimed in Claim 9, arranged 
to print a number of copies of a said document in 
each of a plurality of formats. 

11. A document source as claimed in Claim 10, 
arranged to print only one copy of a said document 
in a first format and an unlimited number of copies 

, of said document in a second format. 
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12. A document source as claimed in Claim 10 or Claim 
1 1 , wherein said formats comprise different resolu- 
tions. 

1 3. A document source as claimed in any one of Claims 5 
10 to 12, wherein said formats comprise mono- 
chrome and colour images. 

14. A fair exchange method of enabling a consumer to 
obtain a document from an owner upon a payment, 10 
the method comprising the use of a protocol involv- 
ing the consumer, the owner and a printer, wherein 
the owner transfers a document to the printer and 
the consumer transfers a payment to the owner, the 
printer interacting with the owner and the consumer 75 
to ensure that the consumer receives the document 
only when the payment has been made. 

15. A cryptographic method of enabling a first party to 
obtain an item of value from a second party upon 20 
receipt by said second party of a second item of 
value, the method comprising the use of a protocol 
involving the first party, the second party and a 
source of said first item of value, wherein the 
source requires knowledge of a key in order to pro- 25 
vide the said first item of value, the protocol com- 
prising the following sequential steps: 

(a) the first party requests a specified first item 
of value; 

(b) the second party provides the source with a 
first portion of the key; 

(c) the first party provides the second party with 
the second item of value; and 

(d) the second party provides the source with a 
second portion of the key, which can combine 
with said first portion to generate the complete 
key. 

16. A fair exchange method of enabling a contract 40 
between a buyer and a seller of a commodity com- 
prising the use of a cryptographic protocol involving 

the buyer, the seller and a source of said commod- 
ity, the source interacting with the buyer and the 
seller to ensure that the buyer receives the com- 4s 
modity only when a payment has been made by the 
buyer to the seller. 
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